Computerized systems provide many advantages towards peoples' ability to perform tasks. Indeed, the computer system's ability to processes information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems where preformed manually. Further, computing systems have been coupled together to form computer networks over which the computer systems can communicate electronically to share data. As a result, many of the tasks preformed at a computer system (e.g., accessing electronic mail, web browsing, etc.) include electronic communication with one or more other systems via a computer network (e.g., the Internet).
Often, electronic communication on a computer network includes a client computer system (hereinafter referred to as a “client” or “user”) requesting access to a service (e.g., electronic mail, web service accounts, etc.) at a server computing system (hereinafter referred to as a “server” or “service”). Before allowing the client access to the service, the server will typically issue a challenge to the client requiring the client to prove its identity. Accordingly, the user will respond providing the service with the user credentials, e.g., a token, certificate, username and password, etc. Once authenticated, the user is given authorization, which allows the user to perform actions (e.g., delete, created, move, modify, etc.) on various resources (e.g., folders, messages, processes, etc.) based on privileges associated with the user's account. When the client is through communicating with the server, the connection is severed.
The above described buildup and tear down of communication channels between a client and a server is a very costly process. Accordingly, a high volume of client connections can severely slow or even shutdown processes on the server. In order to reduce some of the processing burdens of such servers, newer topologies are emerging that utilize front-end and back-end servers. These topologies use front-end servers to provide a lot of the functionality for processing services, while back-end servers are used mostly to store the data corresponding to the resources. As such, the front-end services acts as a load balancing device for the back-end providing functionality that was previously only performed by a single server. In other words, there can be several front-end services acting on behalf of a host of clients, yet only a single back-end is used to access resources for all of the clients. Note, however, that a client must now authenticate themselves to both servers in order to gain access to each one.
For credentials that are delegable by default, (e.g., username and password) the above topology does not pose a significant problem since the front-end server can use such credentials to impersonate the client to the back-end. Non-delegable credentials (e.g., operating system tokens, digital certificates, and the like), on the other hand, have created some problems for such topologies. In an attempt to rectify this and other deficiencies, some systems provide for a general delegation that allows the client to authenticate using a certificate at one server and then allow access to all other servers within the network or enterprise. As can be seen, however, this poses a high security risk and has some of the same shortcomings of providing delegable credentials, i.e., it allows full access to the network.
To combat the concerns of general delegation, another mechanism called constrained delegation has been created. In this infrastructure, delegation is limited to a predefined set of servers within the network. Although this is a great improvement over general delegation systems, constrained delegation topologies also have their shortcomings. For example, these infrastructures are very complex and require a high degree of skill to appropriately configure. Further, many systems require use of the same versioning of software and/or hardware for each of the servers within the network. Commonly, however, systems have mixed configurations and thus will not be able to use constrained delegation. In addition, constrained delegation requires a two-way trust between the delegable servers. Accordingly, resource forests with only one-way trust cannot take advantage of this feature.
Nevertheless, even if constrained delegation or general delegation where used, similar latency problems as previously discussed arise for these topologies as well. In particular, connections from the front-end to the back-end require a fixed identity pipe for the communications. Accordingly, each client requesting access to as m a resources on the back-end must be given a communication channel with the same costly buildup and tear down procedures described above.